Make the app the product, not the CLI - #19

Review found four things worth fixing and one worth defending.

- `resumePending` could run before the transcript handler existed. The
  handlers were installed from their own unstructured Task while
  `loadModel` started immediately; warm-up is always slower than two
  actor hops, so nothing ever observed it, but "always slower" is not
  an ordering guarantee. They are now one chain:
  `installCoordinatorHandlers()` is awaited inside `loadModel` before
  warm-up, and the retry path re-enters it harmlessly.
- A tap that failed while Accessibility read as granted left no row at
  all: `setSetupNeeds` had already run, so the menu looked complete
  while the hotkey did nothing. `evaluateSetup` now builds the whole
  needs set — including a `hotkeyTap` row pointing at the Accessibility
  pane, which is what a stale grant actually needs — and publishes it
  once, after the tap attempt.
- README claimed "then you are offline forever", which stopped being
  true the moment yap started checking for updates. It now says what
  the network is used for and that it can be switched off.
- README listed the hotkey names in camelCase while the recorder writes
  them lower-case. It documents the canonical spelling and notes that
  parsing ignores case and separators, and the test that covers that no
  longer calls it a legacy path, because it never was one.

Recorder capture is now tested directly — right Option commits on
release, F5 alone is accepted, a bare letter is refused with "needs a
modifier" and writes nothing, Escape cancels, a chord commits on
key-down — against real NSEvents built from CGEvents, so the sided
modifier bits are the real ones. 37 tests.

Every button stayed live for the 160 ms of the fade, so a double-click
ran the action twice. On Delete that meant two "Deleted" toasts and a
second trashItem failing on a folder already in the Trash — reported to
the user as an error they did not cause. Clicking Delete and then Open
did both, for the same reason.

The claim is synchronous, in the click, because the moment before the
fade starts is the only point where the two clicks are still
distinguishable. It covers all five actions: a panel is a question, and
a question is answered once.

Three tests, each confirmed to fail with the guard removed (two
deletions instead of one; the second button answering as well) while
the single-click control keeps passing. Then the same thing against the
running app: three real clicks inside the fade on a live transcript
pill produce exactly one `⌫ trashed` and no error.

The acceptance sweep has to come back empty, and a runtime filter for
`--skip-doctor` is a compatibility shim however well it was measured.
It is gone, and the upgrade it existed for is handled where the upgrade
happens.

The failure is real and reproduced on this machine before changing
anything: a 0.2 plist against a 0.3 binary gives `last exit code = 64:
EX_USAGE` and `state = spawn scheduled`, which is KeepAlive relaunching
a job that can never start.

The cask postflight now rewrites `ProgramArguments` with plutil before
restarting, and does it with bootout + bootstrap rather than
`kickstart -k`, because launchd reads a plist when the job is
bootstrapped and not again — a kickstart relaunches the arguments it
already holds in memory, rewritten file or not. Verified against the
reproduced loop: the job comes back up and the plist is byte-identical
to a clean install.

`LaunchAgent.refreshIfStale()` stays. It is not a shim: it maintains our
own file, has no retired argument in it, and covers the DMG path — drag
the new app in, launch it, and the login item is corrected.

Known gap, stated rather than papered over: someone on 0.2 with launch
at login who upgrades by dragging a DMG and reboots without ever
launching the app gets the loop, until they launch yap once or delete
~/Library/LaunchAgents/com.terrifiedbug.yap.plist. Homebrew — the
documented way to install — is covered.

I had the recorder writing `rightoption` where yap 0.2 wrote
`rightOption`. That was my invention and it was wrong twice over: the
plan's own acceptance line says recording right ⌥ writes
`"rightOption"`, and `HotkeyMonitor.Key` was a String enum whose
`rawValue` the Settings window wrote straight into the file — so every
existing config with a right-hand modifier already contains that exact
spelling.

Two spellings for one binding is what made the second look like a
compatibility path. There is one now, and it is the incumbent. Nothing
migrates, nothing is rewritten, and case-insensitive parsing stays
exactly what `Key.init(name:)` always did — it is for the file people
edit by hand, not for a retired API.

Verified live: a config saying `"hotkey": "rightOption"` hot-reloads
into `idle · hold Right ⌥ to dictate`, and the file is left untouched.

"No new processes" is the rule, so the updater stops being an exception
to it. `ZipArchive` reads the central directory and inflates entries
with the Compression framework — stored and deflated entries,
directories, POSIX modes, and a refusal for anything else.

Two things make that safe enough to hold bytes that have not been
signature-checked yet:

- Entry names are resolved and checked for containment, so an archive
  naming `../../bin/something` is refused rather than written.
- Symbolic links are refused outright. The containment check is
  lexical, so a link entry creating `staging/link -> /elsewhere` would
  let every later `link/...` entry pass a text comparison while the
  write followed the link out of staging — before verification. A yap
  release contains no symlinks (measured: zero, in both the bundle and
  the artifact), so the class is removed rather than raced, and it
  fails loudly the day a release embeds a framework.

AppleDouble sidecars are dropped. `build-release.sh` already runs
`xattr -cr` before signing, and a bundle extracted without them
verifies — checked, not assumed.

Proof, on a real Developer ID-signed 9.9.9 build served from a local
feed: our own extractor's output is a byte-identical tree to `ditto -x
-k` of the same archive, reports "valid on disk" and "satisfies its
Designated Requirement", passes the updater's own
SecStaticCodeCheckValidity, and installs — /Applications/yap.app came
up as 9.9.9 with a valid signature and no quarantine xattr.

Sources now spawn a process in three places, all of them inherited from
main: osascript for notifications, /bin/sh for the on_stop hook, and
launchctl. The update path spawns none.

"Nothing runs while idle" names timers directly and permits exactly one
piece of background work, which is meeting detection. A 30-second work
item plus a repeating daily Timer, armed at launch because the setting
defaulted on, was neither of those things. It is gone, along with the
`updates.automatic` key, the Settings toggle, and the launch and
config-reload callsites that armed it.

What is left is the whole of the feature minus the schedule: "Check
Now" in Settings → General does one request, verifies, stages, and puts
"Update to x.y.z · Restart" in the menu. yap makes no network request
of its own after the model is on disk unless someone clicks that.

Measured after the cut, on the installed daemon sitting idle: 0.0% CPU
over a minute. Every remaining timer in the tree belongs to something
happening — the menu's elapsed counter while a session records, the
pill's auto-dismiss while a pill is up, the session stall check while
recording, the config watcher's debounce, the dictation suppression
tail — plus MeetingDetector, which is the permitted one.

An existing config keeps its `updates` block: unknown keys are left
alone by design, and reading one is not worth rewriting someone's file.

Two corrections to the previous commit.

Registering the observer in `start()` looked free and was not: touching
`Updater.shared` constructs it, and its init asks the code-signing
machinery who signed us. Measured cold, which is how it runs at launch:
6.5-17 ms, ahead of the status item that is supposed to be on screen
inside a second. It moves after warm-up, where the scheduling used to
live. Nothing is lost by waiting — `observe` replays the current state
to a new subscriber.

Then the more important half: it went after warm-up, not inside the
success branch. A build whose model will not load is the one a user
most wants to replace, and the Restart item only ever appears for a
daemon that is watching the updater — so a failed warm-up would have
left Settings able to stage an update that the menu could never offer.

`observeUpdates` also guards on already having a subscription: "Retry
Model Download" re-enters `loadModel`, and a second registration would
leave the first in the observer map firing forever.